<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Do you need Berkeley DB?</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="intro.html" title="Chapter 1.  Introduction" />
    <link rel="prev" href="intro_dbisnot.html" title="What Berkeley DB is not" />
    <link rel="next" href="intro_what.html" title="What other services does Berkeley DB provide?" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Do you need Berkeley DB?</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="intro_dbisnot.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 1.  Introduction </th>
          <td width="20%" align="right"> <a accesskey="n" href="intro_what.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="intro_need"></a>Do you need Berkeley DB?</h2>
          </div>
        </div>
      </div>
      <p>
        Berkeley DB is an ideal database system for applications
        that need fast, scalable, and reliable embedded database
        management. For applications that need different services,
        however, it can be a poor choice.
    </p>
      <p>
        First, do you need the ability to access your data in ways
        you cannot predict in advance? If your users want to be able
        to enter SQL queries to perform complicated searches that you
        cannot program into your application to begin with, then you
        should consider a relational engine instead. Berkeley DB
        requires a programmer to write code in order to run a new kind
        of query.
    </p>
      <p>
        On the other hand, if you can predict your data access
        patterns up front — and in particular if you need fairly
        simple key/value lookups — then Berkeley DB is a good
        choice. The queries can be coded up once, and will then run
        very quickly because there is no SQL to parse and
        execute.
    </p>
      <p>
        Second, are there political arguments for or against a
        standalone relational server? If you're building an
        application for your own use and have a relational system
        installed with administrative support already, it may be
        simpler to use that than to build and learn Berkeley DB. On
        the other hand, if you'll be shipping many copies of your
        application to customers, and don't want your customers to
        have to buy, install, and manage a separate database system,
        then Berkeley DB may be a better choice.
    </p>
      <p>
        Third, are there any technical advantages to an embedded
        database? If you're building an application that will run
        unattended for long periods of time, or for end users who are
        not sophisticated administrators, then a separate server
        process may be too big a burden. It will require separate
        installation and management, and if it creates new ways for
        the application to fail, or new complexities to master in the
        field, then Berkeley DB may be a better choice.
    </p>
      <p>
        The fundamental question is, how closely do your
        requirements match the Berkeley DB design? Berkeley DB was
        conceived and built to provide fast, reliable,
        transaction-protected record storage. The library itself was
        never intended to provide interactive query support, graphical
        reporting tools, or similar services that some other database
        systems provide. We have tried always to err on the side of
        minimalism and simplicity. By keeping the library small and
        simple, we create fewer opportunities for bugs to creep in,
        and we guarantee that the database system stays fast, because
        there is very little code to execute. If your application
        needs that set of features, then Berkeley DB is almost
        certainly the best choice for you.
    </p>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="intro_dbisnot.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="intro.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="intro_what.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">What Berkeley DB is not </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> What other services does Berkeley DB provide?</td>
        </tr>
      </table>
    </div>
  </body>
</html>
